The present application generally relates to systems and methods for the management of exceptions such as adjustments or deductions taken by buyers with regard to payments sent to a seller. More specifically, the present application presents an automated system and method for processing adjustments such as deductions taken by a buyer or credits to a buyer with regard to payments sent to a seller, processing the transaction at the seller's side, closing out the transaction and updating the seller's accounting system.
FIG. 1 illustrates a typical transaction 100 for the purchase of goods according to the prior art. As shown in FIG. 1, the transaction involves a buyer 110, a seller 130, and a financial institution 120. Typically, the buyer 110 sends a purchase request 102 or purchase order to the seller 130. The purchase request 102 identifies the goods the buyer 110 desires. The seller 130 receives the buyer's purchase request and then ships the goods to the buyer 110.
Along with or separate from the goods, the seller 130 may send a statement or an invoice 105. The invoice 105 typically lists the goods being shipped and may include other information such as price, quantity, a seller coding or identification such as a SKU number and/or other order information. Alternatively, instead of a single invoice for a single shipment, a statement reflecting multiple shipments may be employed in situations where multiple shipments are sent to the same buyer.
Once the buyer 110 has received the seller's goods and invoice 105, the buyer 110 must pay for the goods at that time or at some time thereafter. Presently, in many cases, buyers pay for goods using any of a variety of methods including cash, checks, credit cards, Automated Clearing House (ACH) or other electronic/wire transfer. Regardless of the method of payment, the buyer's payment and/or information is remitted to the financial institution 120 as remittance information 115. In some cases the payment and/or information is sent initially to the seller 130, who then passes it along to the financial institution 120.
The financial institution 120 receives the buyer's payment and remittance 115 and deposits the funds in seller's account at the financial institution 120. The financial institution 120 then alerts the seller 130 that a payment has been received by sending payment data 125 to the seller 130.
The payment data 125 may take the form of a monthly, weekly, or typically a daily account summary. In the most preferable configuration, the account summary is updated several times a day. The payment data may also be electronically sent to the seller 130 or may be provided to the seller 130 by allowing the seller to electronically access the financial institution's records or photocopies may be mailed to the seller 130.
Additionally, as mentioned above, the buyer's payment may be received in any of a variety of methods. However, regardless of the type of payment received, the payment is typically converted to an electronic expression by the financial institution. For example, a paper check that is received by the financial institution may be scanned or imaged and the payment data on the face of the check may be converted into an electronic expression by a data entry person at the financial institution 120. ACH or wire transfers are already in an electronic form, but the financial institution's record of the transaction may also reflect the originator of the ACH and the date of the ACH, for example. Typically, most of the bank's electronic data is sent to the seller 130 as the payment data 125.
Once the payment data 125 has been received by the seller 130, the seller 130 must then begin the laborious task of matching each received payment with the corresponding invoice. That is, in order to confirm that the buyer 110 has paid for the goods that were shipped, the seller 130 matches the payment data 125 received from the financial institution 120 to the invoice data 105 that was sent to the buyer 110. Once the seller 130 has matched the invoice data 105 to the payment data 125, the transaction is said to be closed-out, provided that the invoice data matches the payment data exactly. For a seller with a large number of invoices, this process may be very time consuming.
Additionally, until the payment data 125 has been successfully matched to the invoice data 105 by closing out the transaction, the seller 130 does not know whether the correct payment has been received from the buyer 110. The buyer 110 may have over or underpaid, for example. Consequently, until the transaction has been closed out, the seller 130 can not be sure whether the current balance reflected in the seller's account at the financial institution 120 represents available cash or whether some amount is due back to the buyer 110 as an overpayment, for example.
As may be expected, matching payment data to invoice information may be quite time consuming, especially when the seller 130 is shipping goods to a large number of buyers 110. Additionally, matching payment data to invoice information may be further complicated by the time lag between the time the invoice 105 was sent to the buyer 110 and the time the payment data 125 was received by the seller. Additionally, matching payment data to invoice information may be further complicated because the received payment data 125 may not match the invoice 105.
That is, the buyer may submit a payment that differs from the invoiced amount. The payment submitted by the buyer may be less than or greater than the invoiced amount. For example, the payment submitted by the buyer may be less than the invoiced amount when the buyer's payment is not for all of the goods, for example, such as when some of the goods are not received or are damaged. Additionally, the buyer's payment may be less than the invoiced amount due to a disagreement as to price or quantity of goods or of a discount received by the buyer. Conversely, the payment submitted by the buyer may be greater than the invoiced amount due to errors by the buyer such as typographical errors or billing discrepancies or when the buyer pre-pays or over pays.
When a payment received from a buyer does not match the seller's invoice, an adjustment to the invoice is typically made. When the adjustment results in a lessening of the invoice amount, the adjustment is referred to as a deduction (also known as a chargeback or dispute). Typically, the customer demands an adjustment. This demand for an adjustment is commonly referred to as an adjustment request. Though a deduction doesn't necessarily have to reference a specific seller's invoice, adjustment requests are typically in the form of a deduction in the invoice amount. For example, when a customer receives damaged goods, he or she demands that the invoice amount be reduced to reflect that the good had been damaged, and therefore demands an adjustment request in the form of a deduction in the invoice amount. Additionally, the buyer's payment may not match the seller's invoice if the seller's invoice was in error from the start. Alternatively, a buyer's invoice may be given an adjustment such as a buyer-specific discount, for example.
An adjustment request may be in several forms. For example, the adjustment request may be a phone call from the buyer to the seller requesting an adjustment. Also, the adjustment request may be a letter or email from the customer to the seller. In addition, the adjustment request may be the invoice with the demand for a refund of overpayment or deduction in the invoice amount written on the invoice. Alternatively, the adjustment request may also be any form of electronic communication such as electronic data from a website.
Once the adjustment request has been received by the seller, the adjustment request is typically passed to a human for review. The reviewers are individuals who review the adjustment request and the relevant documents in order to approve or deny the adjustment request. The consent of more than one reviewer may be necessary to allow a particular customer to make an adjustment. Once all of the reviewers have reviewed the adjustment request and all the relevant documents, the adjustment request is either approved or denied.
If the seller approves the adjustment request, the seller either issues a credit to the customer. Re-invoicing the buyer typically has a similar effect on the seller's accounting system as issuing a credit to the customer. Conversely, if the customer requests an adjustment in the form of a deduction in the invoice amount, and the adjustment request is approved by the seller, the seller reduces the invoice amount and accepts a lower payment from the buyer.
FIG. 2 illustrates a typical work flow 200 for a processing a transaction for selling goods. First, at step 210, the sell side 201 sends an invoice to the buy side 202. Next, at step 220, the invoice is initially reviewed by the buyer. Any disputes are handled in step 230, for example by making an adjustment. Also at step 230, any dispute or adjustment is reviewed and approved by the buyer. As discussed further below and indicated in FIG. 2, the dispute and adjustment process may be quite time and labor consuming for the seller. Finally, at step 240, payment is sent from the buyer to the seller.
Note that in step 240, the payment received from the buyer is often manually matched to an invoice at the seller, which is quite time consuming. Even if some data is electronically provided, the buyer's payment systems are typically not equipped to process the received data without substantial human interaction. Additionally, at step 230, the adjustment or dispute process is identified as labor intensive and lengthy for both the buyer and the seller.
Thus, current systems for resolving adjustments are overly costly for a number of reasons. First, there is an abundance of information to monitor. This information includes customer information, invoice information, the cause for the adjustment request (i.e., whether a deduction or overpayment refund is being sought), past invoices of the customer, past adjustment requests from the customer, and the customer's credit line with the seller, and may include other information.
Second, in large businesses, there is often an inability to ensure that all of the relevant departments of the seller (for example, the accounting department, shipping department, and credit department, among others) are able to review, edit, and approve or deny the adjustment request. This inability to ensure that all of the relevant departments of the seller review the adjustment request stems from the manual coupling of the adjustment request and the relevant documentation, as discussed above. Undoubtedly, errors occur on a frequent basis where, for example, a reviewer does not receive all of the documentation that he requires to properly review the adjustment request.
In a related problem, third, it may be very difficult to ensure that all relevant departments of the seller perform their reviews in a timely manner, especially when several departments are involved. For example, delay in ensuring that a first reviewer receives all of the documentation required for his review of the adjustment request will cause further delay for subsequent reviewers. In this way, when other reviewers are waiting for the first reviewer to complete his review of the adjustment document and relevant documentation, delay in the processing of the adjustment request ensues. This delay becomes even more troublesome when multiple levels of review (that is, one reviewer must wait and review a first reviewer's resolution of the adjustment request) are required by the seller. For example, where a seller requires that all initial reviews of an adjustment request be reviewed by a manager of reviewers, any delay in routing the information to, and receiving a resolution from, one or more of the reviewers will only cause additional delay.
Finally, any delay in ensuring that all relevant departments review the adjustment request will cause additional delays in pursuing collection of a debt owed by a customer or in issuing a refund owed to a customer. This can cause business losses due to lengthy collection delays and a loss of customer goodwill. In addition, current systems and methods do not provide for integration between the adjustment management system and method and the bank of the seller. This, in turn, causes additional delay in the final resolution of adjustment requests. This delay will be because the seller will have to notify the customer, who will then have to send payment to the seller. In a similar manner, any posting of money owed to the customer will also be delayed.
Thus, a need has long been felt for a sales adjustment management solution that eliminates or minimizes many of the problems associated with current systems. A need has especially been felt for such a system that is capable of handling a large number of adjustment requests in order to reduce unnecessary write-offs by a seller. Also, a need has long been felt for a system to reduce the labor and time investment for processing the adjustments. Additionally, a need has long been felt for a flexible system that may be used to process a wide variety of adjustment requests. Finally, a need has long been felt for an adjustment system that is directly integrated with the seller's financial institution.